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At the Spring US Symposium we officially change I our designation to 12 Bit 
Special Interest Group to reflect an area of it -erest that has spread beyond 
just OS/8 to include most PDP-8 and PDP-12 fami y hardware and software 
issues. I have appointed a steering committee *or the S.I.G. The initial 
committee consists of Tom Mclntyre, Jim Crapuch ttes, Jim Coryell and myself. 

Under the provisions of the new US Bylaws that ; How appointment to the US 
Executive Board of representatives of Special U: er Groups we requested such 
representation at the last US Board meeting. 0? ly one Special User Group is 
presently so represented - the DEC system 10/20 group. The US Board "tabled" 
our request and asked for various reports and/oi presentations before further 
consideration. In view of the fact that we are the oldest and largest S.I.G., 
the fact that we have pioneered the S.I.G. cone* ot and served as the model for 
most of the new S.I.G. 's that have come along si ice we started and particularly 
in view of the special needs and problems of th« 12 Bit User community that 
cannot be fully represented otherwise I hope the Executive Board will act 
favorably on our request at the earliest possible opportunity. 

INPUT TO DECHg FALL US SYMPOSIUM 

DEC is interested in seeing scheduled, for the FOl DECUS, papers by users 
whic'i describe their need3 in two particular are is. They feel such input will 
be helpful in considerations for future design p tases. The two particular 
areas are: 

1. Multi processing needs. 2. Transaction processing needs. 
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SPRING SYMPOSIUM ATTENDANCE 

EECUS' new B3 310 (i.e. , PDP-8/A) reports that ve had 217 PDP-8 users at 
the Spring Symposium o;rt of a total attendance of 790. That is not bad 
considering the comparatively restricted 12 BIT program. The program for 
the Las Vegas meeting i hould be considerably more extensive with panels and 
workshops scheduled to give some opportunity to talk to those who cannot 
submit formal papers before the deadline. If yoa have anything special 
along these lines, contact me or Tom Mclntyre as soon as possible. 

EECUS EUROPE SYMPOSIUM 

The 1976 European meeting is scheduled for September 8, 9 and 10 in Munich. 
Gordon Bell will be a featured speaker. DECUS Europe and DEC Europe Educa- 
tional Services are combining forces for training seminars the two days be- 
fore the meeting. The European 12 BIT SIG will offer a half-day draining 
Seminar. It will be supplemented for those who request it , by & one and 
a half day DEC program. The 12 BIT SIG is planning an interesting end 
varied program. 

The combined Training Seminar will cover RTS-8 along with SIG material on 
TECO, FORTRAN and "BAL" (PAL?). The RTS-8 program will cover multitasking 
system overview, executive description, background/foreground, communication 
rules, system generation, and examples. It should prepare the attendee to 
describe the RTS— 8 system, implement programs in the system and configure 
an RTS-8 system. The student must be familiar with OS/8. 

SIG Meeting Report 

The Atlanta meetiig began a new procedure for the Mini-Midi DECDS 
efforts to record sessions and provide the tapes to the Chairmen or 
in this case the symposia representative to abstract and report 
upon in the news letter. This is a set of loose observations 
derived from such a tape of 'the 12 bit SIG and PDP-8 Software 
Workshop meeting. The meeting began with Bob recapping the 
formation of the 2 bit SIG as outlined in the Steering Committee 
Report. The members of the initial Steering Committee are Bob 
Hassinger, Chairman and Newsletter Editor, Jim Coryell, Library 
Representative, Tom Mclntyre, Symposia Committee Representative, 
and Jim Crapuchettea. 

Bob Bean gave a synopsis of the progress in the PDP-8 Software area 
since last December appropriately entitled deja vu. There has been 
considerable progress in the DECnet software for the PDP-8 and it 
was reported that field tests would be beginning about this time. 
A very impressive I ECnet ueno was of course running in the machine 
room and we were informed that it was a real piece of software and 
not a midnight special as we had seen in Los Angeles. MACREL is 
officially under development now but is not officially announced. 
This caused some confusion among the audience but I think Bob 
Bean's answers were reasonably to the point. The major point is 
that DEC can no longer do any major software developments on the 8 
without MACREL so we can be confident it will actually happen. We 
were told, also unofficially that some of the original developers 
of OS/8 would be available to assist with the MPiCREL/Linker 
project. 
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A" question was raised from the floor on which problems had been 
corrected in the OS/8 V3C release. The answer was that the list of 
fixes was contained in the release notes. Some interest was 
expressed in having that information published, perhaps in a future 
12 bit S1G newsletter. The problem was pointed out by Bob 
Hassinger that frequently the user's description of his problem 
does not mesh perfectly with the description in the fix. Bob also 
commented on softwc re lag time which is typically now about 6 
months from the final code version to SDC shipment of the product. 
This time represents engi taring testing and kit preparation and 
many other areas of t£ying to achieve a more reliable software 
product. We all wish it were shorten but for maximum reliability 
it should probably be even longer. The price on the current V3C 
release was apparently settled as representing a similar level of 
effort to the current RT-11 update which carries the same price. 

Gary Cole was introduced and gave us a little history of how DEC 
got into the software business. Gary's \nain point was not 
historical but rather that good software cannot be had for free 
regardless of how cheap the system is. The story of the PDP-15 
software maintenance was very instructive in this regard. The 15 
was the first "small" system to have software maintenance and as a 
result of the effort to make a profit on the maintenance service, 
the products became so reliable that the maintenance was no longer 

needed and has been dropped. Gary's top of the head estimate on 
the ratio of software development time to test and certification 
time for reliable item was about 1:3. With such testing it could 
be reasonably expected that maintenance releases would not be 
needed. 

There was considerable discussion of documentation and we flushed 
out Armand Vartaressian (who I hope will forgive my spelling of his 
name) who is.J now in charge of PDP-8 documentation. Armand is 
looking for specific inputs about the RTS-8 Users Guide and the 
OS/8 Handbook. The notion was presented that perhaps the OS/8 
Handbook could consist of a small users Pocket Guide (approx 150 
pages) and a large loose leaf reference manual (approx 1000 pages) . 
The question came up of whether the smaller manuals could be 
distributed in machine readable (2UN0FF) form and was given a 
tentative affirmative answer. The larger manual was considered to 
be too long for machine readable distribution. (I have since 
calculated that 1000 pages is approximately 2.5 Million characters 
which would fit easily on an RK disk.) Bob Gappaert (to whom I also 
apologize for spelling) the Manager of Software Documentation 
reported that they have been studying the distribution of machine 
readable documentation and have okayed everything but the cost. He 
promised that they would have an answer to the question within two 
months (which is about now) . 

Several individuals suggested that they would like to see a 
hierarchy of handbooks at various levels from introductory to 
advanced levels. Another alternative suggested was to make the 
various chapters of the OS/8 type book available separately. 

Bob Bean ended the session at the coffee break with a plea for more 
inputs in the area of language and operating systems developments. 
I believe it would be especially useful to orient our thinking in 
terms of the foreground/background systems and try to determine 
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which utilities language features, etc would Be most valuable in 

that environment. I am particularly thinking of such things as 

second partition spoolers or multi-user language systems such as 

the RT-11 MU BASIC. The more inputs Bob gets the better off we 
are. 

Steering Committee Report 

The 12 bit SIG Steering Committee held its first meeting at the 
Spring DECOS meeting in Atlanta. Members present were: Bob 
Hassinger, Jim Crapuchettes and Tom Mclntyre. Mario DeNobili was 
present as a spirit observer. Our major concerns were in 
maintaining representation for the 12 bit machines on the DECOS 
Bxecuti/e Board and finding new avenues of communication with the 
approximately 50,0B0 family of 8 users. 

We have no firm handle on the representation problem but have 
petitioned the Executive Board for a 12 bit mainframe 
representative position. With respect to the second area of 
concern we came up with two reasonably concrete ideas. 

The first idea is to have an announced theme for the 12 bit SIG 
sessions at the DECUS meetings. We feel that if the prospective 
attendees know in advance the areas to be covered they will be able 
to prepare formal presentations a.id workshops along that theme. 
For the Las Vegas meeting we are proposing that the theme be real 
time systems and communications software. We hope to smoke out 
people with experience implementing RTS-8 systems or users of other 
real time systems. In the communications area I suspect that some 
of the older terminal emulator applications have been converted to 
RTS-8 amdn we all would be very interested in the problems 
encountered and solutions found. 

Our second idea was to attempt some sort of regional meetings. We 
have had several people volunteer to organize one day (approx.) 
meetings in specific regions. Fred Brandt of Gal laud et College in 
Washington DC has volunteered his services; Norm Dotti has 
volunteered to organize a meeting in the Chicago area; Jim 
Crapuchettes will be trying to set something up in the San 
Francisco area; Jim Coryell will be working on the Los Angeles 
area; and Stan Rabinowitz has agreed to organize something in the 
Boston area. If any others are interested in setting up a short 
regional meeting please let us know. The format for such meetings 
is not settled, but the general picture would be a semi-open house 
at a local installation and either a general discussion seminar or 
short course on a specific topic. The local committee would set up 
motel arrangements if necessary and people would probably spend one 
night and one day at the meeting. The SIG would consider 
developing program packets and materials for such meetings, but 
this likely would require some sort of registration fee and 
complicate matters somewhat. The general intent is to provide a 
less expensive alternative to the semi-annual DSCUS meetings for 
those who can't afford the time or perhaps the money for the 
latter. Our thoughts are still in the formative stage and we would 
appreciate any inputs you might have. 



Tom Mclntyre 
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Dear Bob: 

At Decus, you kindly offered me an opportunity to contribute ta-your news- 
letter, so with a few hours remaining before your deadline 5 -I finally got down 
to writing. 

Introductions are in order, I am Gary Cole, a 30 year old, ex physicist (al- 
most), programmer, systems designer, marketing person and engineering manager, 
most of it compressed into eight years here at BBC. Ify new role is that of 
"product manager" in our PDP-8 product line. Actually, this is a return to the 
8's after six years of involvement with PBP-15's and the creation of XVM. 

DEC has a number of different roles associated with the "product manager" 
identification, but mine is a fairly clear (a bit complicated) one of directing 
the development of PDP-8 software and hardware and planning the next generation 
of 8's* Coming from a background of large systems is probably a good way to enter 
today's 8 world as we are increasingly able to build sophisticated products in 
low cost packages. So mueh f or introductions. 

Last month's Decus was certainly a well attended one; but there were some dis- 
turbing elements which seem worthy of improvement. There seemed to be rather 
little education taking place in the 8 sessions in comparison tc other groups. 
Much of this can be attributed to a low level of DSC program involvement, but some 
comes from an almost overpowering concentration on one area - C5/8 (es- 
pecially in education). With such a large part of Dec's 8 busaie^s involved in 
real time and communications applications it would seem that k significant amount 
of time should be devoted to these areas, indeed several people expressed con- 
siderable frustration with the lack of BTS/8 sessions. This is an area of great 
concern to me as BTS/8 is becoming a very important product with lots of develop- 
ment left to be done. Even your recent questionnaire shows a strong interest 
in the enhancement of our multiprogramming capability. 

On the other hand, the focus on OS/8 did bring out two important issues. One 

of these was the pricing of software releases and the other was the documentation 

of OS/8. 

Concerning pricing, Dec is going to charge users some of the cost involved in 
releases of our operating systems. Nonetheless, we also understand that there 
is a general need to know when a release is coming and what it will cost. We 
should be able to do a better job of this in the future. 

On the subject of documentation, I believe that all PDP-8 documents could use 
substantial revision - especially the OS/8 handbook. Once we get a good plan 
in place for how the handbook will be re-structured, I'll be communicating it 
to you. 

Dec will be making a much stronger showing at Fall Decus in the 8 world, and I 
hope we can also broaden the range of the sessions to include the needs of more 
PDP-8 owners. 

I'm looking toward the opportunity of meeting many of you in the years ahead. 

Very truly yours, Cary Cole 

PS: While this was written, we manufactured two more PDP-8 family- systems! 
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NEW PROGRAM SUBMISSIONS TO DECUS 

The following programs have been or are being submitted to EECUS but they do 
not have numbers yet. If you feel you need a copy of any of them before a 
number is assigned and they are ready for distribution you will have to con- 
tact the library. This causes an extra workload, though, so only do it if you 
cannot wait until their numbers are published. 

Friedemann Brauer from Germany has submitted two items written by Karlheinz 
Siebold. 

Big PIP is an OS/8 utility program for the transfer of files and specific 

blocks. Files and blocks can be merged to one new file; output to a 
specified block is also possible. The program has proved to be very useful 
in the case of overwritten directories, etc., and the transfer of non-file- 
structured data sets. 

33B8E is an OS/8 interprocessor buffer device handler. Together with the 

slave program IPSLAY it allows handling of any device belonging to the 
slave computer, under the device name IPB. It has been very useful for the 
submitters configuration of one PDP-12, two LAB Se's, and PDP-8f all con- 
nected with interprocessor buffers (used two at a time). 

JIM VAHZES HAS Tift) HEg SUBMISSIONS : 

VC8E. A •TV* handler for a storage scope. It is a two-page handler which 

generates and displays alphanumeric s on a storage oscilloscope using 
the standard VC8E or VC8A controller. Keyboard paging is used to erase the 
screen when it fills up, and optionally to return to the monitor. It is avail- 
able on paper tape and DECtape. 

LABL. An update to the TEXT handler that accepts ASCII characters and punches 

legible leader /trailer on paper tape. It is a very convenient way to 
punch the identification of a paper tape on its leader in a readable form. 
Other ways of doing that have required special programs, but because LABL is 
a standard handler it will work with any program (i.e., PIP, etc.) that ac- 
cepts two-page output handlers. 

FAGE8 

I recently received a package of literature on PAGE8 from Dewar Informa- 
tion Systems, 622 Forest Ave., River Forest, IL 60305. It is a two-pass macro- 
assembler that runs under OS/8. Among its features are Macro facility, Auto- 
matic Paging, Expression Analysis, 6 types of constants, over 50 assembler 
directives, full support of up to 32 K of memory, improved error detection, the 
ability to work as a macro-assembler for other computers (i.e., cross 
assembler) , extensive Cross-reference directory, External Symbol Directory 
for generating a set of definitions for selected symbols that can be included 
in assemblies of other program components, Liberal Reference counts, and Local 
symbols, plus other features such as Table of Contents. It requires* a minimum 
of 16 K to run. 

I do not have access to a copy of PAGE8 so I cannot give a firsthand report 
on it, but I have talked to one or two users who generally feel it is a very 
useful tool. The principle complaint has been that the syntax is distinctly 
unlike'" PAL 8 and it is claimed to be irregular enough to cause some problems. 
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CQKFLICTING DEVICE CODES 

Hans W. Goebel from Purdue University relates an interesting anecdote about DEC 
and the sanctity of device codes in the 12 Bit World. When he first got his 
FPP 12 Floating Point Processor he started having all sorts of trouble with 
his standard EEC AF$h Data Acquisition System. He discovered to his dismay, 
that the AF0k and the FPP 12 maintenance IOTs were on the same device code 
656x! His local service people re-wired the AF01* to device code 6kfx but he 
had no luck trying to get a revised diagnostic for it. He finally had to "dis- 
assemble" all the diagnostic tapes, edit and re-assemble them himself. He 
observes that DEC seems to be trying to live up to its reputation as the IBM 
of the B&ni-computer business. 

I can appreciate DEC f s problem in this situation (I was once in the business 
of designing special peripherals and systems for a main frame manufacturer) , 
but how much would it have cost DEC to give a copy of the sources of the diag- 
nostics to the customer? Maybe some day DEC (and everyone else) will learn 
to make software easily modifiable to accommodate simple configuration fac- 
tors like different device codes and data break locations. 



HOTE FROM JOHH YOUNGQUIST 

John sent a patch for OS/8 EDIT to make rub out work better on CRT terminals. 
I will attach it. He points out the patch is not sophisticated enough to rub 
out back over tabs properly. 

John notes that he has modified the PDP-8e powerfail/auto restart board to re- 
start at 07600, thus bootstrapping OS/8. This allows remote control of an 
OS/8 system. He has a telephone controller that listens on the phone line for 
a special tone that controls power up of the system. The system powers down 
when the sending modem goes off for more than 3 seconds. This allows re- 
booting the system without terminating the call. The modification requires h 
diodes and two wires. The phone control is 6 I C's on a small board. 

He has also modified his KL8E (M8650) serial interface card to allow the break 
key on his CRT to inhibit the flag thus allowing pauses in output (at 2U00 
Band) without special software. 

John's address is: Versus Instruments Inc., Box 112, Fort Erie, Ontario 
(Ul6) 871-0733. 



V3C UPDATE CHAEGES 

Some users have been upset about the increased charges for updates that seem 
to have gone into effect recently. I am attaching a copy of a letter Norman 
Dotti wrote to Ken Olsen and the reply that explains some of the reasons for 
the increase. 
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NOTE FROM JIM WALSH 

Jin sent along a few things. 

1. He had trouble bringing up OS/8 FORTRAN IV in his system with locally built 
A/D, D/A and clocks. When he submitted an SPR the answer was "unable to 
duplicate the problem". Eventually he reached someone in DEC by phone who 
inevr to steer him to page 4-15 of the FORTRAN IV Software Support Manual 
where he found how to insert instructions to count sract the ill effects of 
conflicts between his special IOT's and DEC's that vere creating an unknown 
interrupt condition that was crashing FRIES . 

2. Jim has written a general I/O subroutine for use by FORTRAN II/SABR. It 
requires seven pages of core: four pages for handlers and three pages 
of code. It is designed to allow random access to binary files on any 
device in the system. CALL DECODE allows input of I/O devices and/or file 
names, fetching of appropriate handlers, ENTERs the output file, and LCCHUPs 
the input file. CALL INPUT reads binary data into core, CALL OUTPUT 
writes binary to a device (file). CALL CLOSE closes and saves the file. 

3* Jim is interested in corresponding with anyone who has worked on develop- 
ing an /PL processor for the 8/e. His address is: Jim Walsh, The 
University of Vermont, College of Medicine, Department of Physiology and 
Biophysics, Given Building, Burlington, VT 05^01. 

DFj2 AVAILABLE 

Dr. Andrew Short wrote to say he has a single platter DEC DF 32 disk {32 K 
words) in working order which is about 5 years old. His address is: 
Dept. of Veterinary Physiology, Royal (Dick) School of Veterinary Studies, 
Summerhall, Edinburgh, EH91QH, Scotland. 

OPSCAN 17 HANDLER ISQuTH? 

Dr. David Kay recently acquired an optical mark reader (OPSCAN 17) from 
Optical Scanning Corporation , to be interfaced to his PDP-12 through a DP 12-B 
(data phone interface) with EIA ES 232-C mode of operation. He needs an 
OS-12 (OS-8) handler and DEC does not support one. He would like to hear from 
others who have such a handler. His address is: David C. Kay, M.D. , NIDA 
Addiction Research Center, Box 22390, Lexington*: KY 3*0511. 



Ray Smith wrote to ask for help in contacting anyone interested in developing/ 
using a PL/1 type language for the 8. If you have any interest, contact Ray 
at: 2U-001* MIT, Cambridge, MA 02139 (6l7) 253-^368. 

CORRECTION FOR P3K: AS THE CCL DEFAULT DEVICE ' ■ 

Anyone trying the CCL modification to make DSK: the default device that was 
published in the last Newsletter, will have trouble if he uses it on a tradi- 
tional 8. This is due to the limitation in the original 8 with respect to com- 
bining certain microcoded instructions. I am told that using a STL RTL works 
much better than the IAC RAL that I suggested. 
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Operation of OS/8 BUILD with a 2-page system handler and a long bootstrap 

We are running OS/8 on a PDP8-E with a Sykes 7100 Floppy Disk as the 
system device. For some time we have been using a 2-page system handler, written 
by Mike Peterson, which provides full packing on -the disk (four 12 -bit words into 
six 8-bit bytes) thus increasing disk capacity and page transfer speed. 
As we have reported previously, there are modifications necessary is FRTS and 
BASIC to make them recognise this non-TD8E handler. We have recently tracked 
down a similar problem in BUHD. 

The first indication of trouble was the apparent failure of the BOOT 
command to update the device control word table. We had assumed that block 
of the disk contained the bootstrap followed by copies of the current 176^7-17777 
(Fl resident) and 7600-7777 (F0 resident), but further examination showed that 
with a 2-page handler 'BOOT* writes copies of the updated field 1 resident and 
the field 2 resident onto block 66 of the disk, and that block contains only 
the bootstrap and the F0 resident code. The field 1 resident we were copying 
from block was simply left over from earlier operation with a single-page 
handler and did not contain the updated table. 

It is clearly now possible to accomaodate in the unused portion of 
the first page of block a longer bootstrap than the U7 8 specified by the OS/8 
Software Support Manual; indeed, the TD8E bootstrap length is 103e. If this is 
to be done, however, particularly if the bootstrap length is to exceed IOO9, it 
is vital to inhibit a transfer at 2350 in BUILD of 200s locations from 5^00 
(the block area) into 10000 (the block 66 area) since this may overwrite the 
copy of the USR call routine at 10100. Unfortunately this is only prevented 
if the TD8E handler is recognised in core. This recognition is done at 
locations 2631-3 in BUILD, which will place in vocation k5 if 7612 contains 
3 (as in the TD8E handler). The problem can thus be cleared either by 
incorporating 0003 at location 12 in the first page of the new handler or, less 
preferably, by placing 7200 instead of 1^72 at 2632 in BUILD. 

We are now in a position to have stored on block: of the disk a large 
enough bootstrap to deal with the relatively complex decoding of the full 16-bit 
pecked disk format. Since such a decoding procedure is incompatible with the 
requirement of a very short initial toggled bootstrap, we have adopted a hybrid 
approach whereby the disk-resident part of the bootstrap is stored in a simple 
6-bit-per-byte format which ean be read by a PDP8-E with the very simple coding 
sequence 'READ'; BSW; MQL; 'READ'; MQA; DCA. The required translation of this 
resident coding may be accomplished by writing the precompiled code onto disk 
with a 6+6-bit format program, and reading It off as if it were packed format. 
The resulting code (which incidentally is ^/3 times the final length of the 
bootstrap in core) is then inserted directly into the bootstrap section of the 
handler. 

We are considering writing up the handler and bootstrap for submission 
to DECUS . 



(Drs.) Ian Tempi eton and Peter Holtham 
Physics Division 

National Research Council of Canada 
Ottawa K1A 0R6 
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From: Jim VanZee 

Memo to the OS/12 community regarding LINCtape formatting 

The purpose of this note is to attempt to clarify some of the con- 
fusion regarding the 'uEnoth 1 of OS/8-compatible LINCtapes. To begin 
with, 'OS/12' and 'OS/8' *re simply different names for the very same 
product, distributed in one case on LINCtape and in the other on DEC- 

TAPE OR OTHER MEDIA. 'OS/l2» DOES NOT, UNFORTUNATELY, MAKE ANY USE OF 
THE PDP12 SCOPC ?OR COMMAND INTERACTION, ALTHOUGH A MODIFICATION OF 

Version 2 by D. LLoyd Rice of UCLA ooes have this feature. His version 
OS12/S, is available from DECUS on tape 12-129 and while it would be 

VERY NICE IF SOMEONE WOULD EXTEND IT TO VERSION 3* * T IS A BIG IM- 



ONE OF THE OBVIOUS OMISSIONS OF OS/1 2 IS A FORMATTING PROGRAM. AP- 
PENDIX D of the Software Support Manual mentions that OS/12 uses 129 

WORD BLOCKS JUST THE SAME AS DECTAPES, AND IN FACT THE LINCTAPE HANDLERS 
SUPPLIED WITH THE SYSTEM DO IN FACT MAKE PROVISION FOR SUCH A BLOCK 

length. This 'wierd' length was createo by the MARK12 formatting pro- 
gram WHICH WAS SUPPLIED WITH THE DIAL OPERATING SYSTEM. CHOOSING OPTION 
'P' IN THIS PROGRAM CREATES TAPES WITH 3000g BLOCKS EACH 129 WORDS LONG. 

There are no redeeming features for such a block size. Since OS/8 may 

AT TIMES REQUIRE SIN6LE PAGE LOADS (128 WORDS), THE HANDLER HAS TO SAVE 
AND RESTORE THE 129TH WORD EACH TIME. Th I S OBVIOUSLY RULES OUT INTER- 
RUPT ROUTINES AND OTHER POSSIBLE INNOVATIONS.. 

MARK12 WAS CONVERTED FOR USE WITH THE PS/8 OPERATING SYSTEM BY CHARLES 
M, MOORE AND IS AVAILABLE FROM DECUS ON TAPE 12-95- * SIMILAR PROGRAM 
IS ALSO AVAILABLE ON 12-172 AND A SOMEWHAT DIFFERENT MODIFICATION BY 

John R. Raines comes on tape 12-155* * N these versions option 'P ! for- 
mats 128 WORD BLOCKS, AGAIN CREATING ^OQOo OF THEM. THE LENGTH OF THE 

tape as shown in the directory is not defined 3" the formatting program, 
however, till is established by p|p when the tape is zeroe d or squished, 
pip has a table of device lengths which it consults for all /s and /z 
operations which begins at location i36oo. standard 'os/12' linctapes 
are oevice 17 and the value at location 13^7 always creates tapes with 
737. os/8 blocks - just the same as dectapes. each os/8 block is two 
phystcal LINCtape blocks (either 128 or 129 words) and when all of this 
is converteo to octal, we find that pip only recognizes 2702 out of^ooo 
(octal) blocks createo by MARK12. Thus if you have used MARK12 to format 

YOUR TAPES, YOU CAN FIX UP P|P BY CHANGING LOCATION 13&17 T0 6^00, 00 A 
'/S', AND ADD A FEW MORE BLOCKS TO YOUR EXISTING TAPES. 

Versions of MARK12 released with DIAL-MS allowed another option for 
formatting 'long* dial tapes. doug wrege of the georgia institute of 
Technology has combined these many different versions into a single pro- 
gram called MARKOS which is available from him. This program allows 2 
CHOICES FOR formatting DIAL tapes and 2 choices for formatting OS/8 TAPES. 
Choice 'S 1 creates 737 OS/8 blocks consisting of twice that number of 

128 WORB BLOCKS WHILE CHOICE 'N' ALLOWS THE USSR TO SPECIFY ANY NUMBER HI 

likes. Typically it is possible to format tapes with at least 900 blocks, 
in fact most users find they can always get 927 and sometimes more. The 
exact number depends upon the characteristics of the tape drive w!th the 

OLDER DRIVES (THE ONES WITH THE BIG SWITCHES) SEEMING TO RUN SLIGHTLY 
SLOWER THAN .HE NEWER DRIVES AND HENCE ALLOWING MORE BLOCKS TO FIT ON A TAPE 

IT IS COMMON TO SPECIFY A BLOCK COUNT ENDING IN ''~('' SINCE THE FIRST 7 
BLOCKS ARE RESERVED, LEAV'NG AN 'EVEN 1 NUMBER OF 'FREE BLOCKS 1 . ONCE AGAIN 
THE NUMBER OF TAPE BLOCKS RECOGNIZED BY OS/1 2 IS OETERMINEO BY THE CONSTANT 
IN PIP, NOT BY THE FORMATTING PROGRAM. FOR TAPES W I TH 9 2 7 BLOCKS THIS CON- 
STANT SHOULD BE 6*\kl - E*SY TO REMEMBER SINCE THIS IS THE ' L I NC • INSTRUC- 
TION J FORMATTING YOUR TAPES WITH MARKOS CAN OBVIOUSLY INCREASE THE STORAGE 



MEMO to OS/12 
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CAPACITY OF A TAPE ssUITE DRAMATICALLY, HOWEVER IT IS POSSIBLE TO 00 STILL 
BETTER BY USING 2^)6 WORD BLOCKS SINCE THIS ELIMINATES THE SPACE REQUIRED 
FOR HALF OF THE BLOCK NUMBERS, FORWARD AND REVERSE CHECKSUMS, ETC. 

Basically OS/12 operates in terms of 256 word blocks. However, in 

ORDER TO BE ABLE TO LO© SINGLE-PAGE HANDLERS, IT IS NECESSARY TO BE ABLE 
TO READ OR WRITE HALF A BLOCK, I.E. 128 WORDS. TlH CLARK OF FRELAN AS- 
SOCIATES (Box 298, Menlo Park, CA) has written a special handler which 
can use standard •dial 1 tapes by buffering the i/o so that only 1 page is 
transferred when necessary. needless to say this is a very tricky handler. 
However, if you are using your tapes as a back-up store, or for archiving 
purposes, you usually want to pack as much data as possible on a tape. 
Also if you are using LINC-mode programs to write data directly on a tape 
it is nice to have super long ones. 

The problem is how to format them. Unfortunately MARKOS does not have 

A 'QUEST ION-AND-ANSWER ' INPUT FOR THE 256 WORD FORMATS, SO IT IS NECESSARY 
TO MODIFY THE PROGRAM ITSELF. Th I S MAY BE DONE SEPARATELY FOR OPTIONS 'L' 
AND »B' (SHORT AND LONG TAPES, RESPECTIVELY), SO YOU CAN CHANGE ONE OPTION 
WHILE LEAVING THE OTHER ALONE. THE CHANGES SHOWN BELOW CAN BE MAOE WITH 
ODT, OR MORE CONVENIENTLY, WITH FUTIL, A 'SUPER ODT ' PROGRAM WRITTEN BY 

Jim Crapuchettes (also of FRELAN Associates) and available as DECUS 8-608. 
To increase option 'L 1 from 10153BLOCKS to 1200o (-6^0|q OS/8 blocks): 
ItiAJtlcdC « 4066/1024 1207 

WKD ^ ' 1*07 V1 000 1177 

ANO TO CHANGE OPTION 'B' FROM 896, Q BLOCKS TO 1007 in BLOCKS ON A LONG TAPE: 

M/»kK^. 4532/1600 1755 

Either pair of locations can be changed to either pair of values. The 
first number is log + the highest block number while the second is just 
the last block number and is used for checking, not for marking the tape. 
Tapes marked in this way must, of course, be read or written by the special 
dl: handler mentioned above, not the regular linctape (lta-) handlers, 
thr, means that they are considered to be a 'different device' by p|p and 
the appropriate table entry for setting the length constant is at location 
13674. Changing this location as shown below and doing a DL: </Z (or ZERO 
DL:) operation will initialize such tapes. 

PlP j 13674/0000 6021 CHANGE FOR 1 007 BLOCKS ON A LONG TAPE 

r * 6800 CHANGE FOR 640 BLOCKS ON A SHORT TAPE 

TO FIT 640 BLOCKS ON A SHORT 050ft) TAPE IT IS NECESSARY TO WIND ONLY 2"3 
TURNS ON AT THE START, SET THE UNIT. TO LOCAL, PRESS THE MARK SWITCH WHEN 
TOLD TO DO SO AND HOLD IT OOWN, THEN QUICKLY FLIP TO REMOTE. Th I S AVOIDS 
THE 'WANDERING 1 WHICH OTHERWISE OCCURS. NOTE THAT THIS PROVIDES ALMOST AS 
MUCH SPACE ON A SHORT TAPE AS IS 'NORMALLY 1 AVAILABLE ON A STANDARD LONG 

(260ft) tape. The choice of 1007 BLOCKS for the latter was motivated SIMPLY 

BY THE DESIRE TO HAVE THE DIRECTORY SHOW f 1 000 FREE BLOCKS* INITIALLY. Th I S 
IS A 3756 IMPROVEMENT OVER A STANDARD OS/1 2 OATA TAPE. THE ONLY DISADVANTAGE 
TO USING 'DL' FORMATTED TAPES IS THAT THEY CANNOT BE USED AS SYSTEM TAPES 
BECAUSE OF THE DIFFICULTIES IN WRITING A SYSTEM HANDLER FOR THE LARGER 

BLOCK size. This means that on a '2-tape* system you will have to MOVE 

FILES FIRST ONTO A REGULAR OS/1 2 SYSTEM TAPE ANO THEN OFF AGAIN ONTO A DL 
SJJQLRAJ5J J LAPE. OF COURSE W I TH A DISK SY STEM T H I£ _JJRANS F E R.^CjQU L_0J3 >E DIRECT, 
^jSjjuru^ U THERE CAN NO R MALLY BE N L Y J_ HL^LA P E ~M^ugfTF/ T_A^ tTm E .>-AnV 
GRAM WHICH PERMITS 2-PAGE HANDLERS CAN USE DL TAPES IN THE NORMAL WAY 
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The flexibility in formatting tapes leads to the problem of haing 
tapes with oifferent numbers of blocks all over the place. |n orler to 
use p|p to do a /s or /z operation you must, of course, know how long 
the output tape is. unfortunately the *=' option in the command decoder 
line cannot be used for this (although it is the obvious and natural 
choice!) so it is usually necessary to standardize on a t most 2 lengths 
and use odt to fix p|p whenever necessary. 

This is a great bother. The cure is to switch to DECSYSTEM-8 which is 

AN ENHANCED VERSION OF OS/8 DEVELOPED BY JOHN R. COVERT AND DOUG WREGE 
AND AVAILABLE FROM DECUS AS 8-6^6. U*DER DS8 TAPES MAY BE CREATED WITH 
A 'PARAMETER* BLOCK WHICH REMEMBERS (lN THE LAST BLOCK OF THE DIRECTORY) 
HOW LONG EACH TAPE IS. ThE » SQ * COMMAND THEN TAKES THIS INTO ACCOUNT. 

The parameter block also allows tapes to be labeled so that they can be 
found automatically by the system. ..and other good things! 

Copying non-standard tapes is also a problem. Again a flexible program 
such as DT/TDCOPY is not currently supplied with OS/12. If you use PIP to 
copy tapes the device length table must be correct for the output tape. If 

YOU ATTEMPT TO USE THE COPY PROGRAM WHICH COMES ON TAPE 12~95 y0u w "- L LOSE 

because this program does not check for the end-of-tape, but simply assumes 
737 blocks; the directory will look ok, but the data will be missing. 1 yo u 
can use fotp to copy tapes without knowing how many blocks they have since 
fotp simply i'ses the number it finds in the directory. fotp can also be 
usec to 'zero 1 a tape which already has a directory using the * • */d command 
However, this will not merge empties across directory blocks so that after 
deleting all the files, the directory may look like: 




This is unfortunate since when you now try to transfer programs to this 
completely empty tape they will not go at the beginning! the reason is 
that fotp trj eg frj* f|t programs into empty areas which are roughly the 

SAME SIZe/whTl'eJOTHER PROGRAMS USUALLY PUT OUTPUT FILES IN THE LARGEST 

empty. Thus FOTP would put a 2^0 block source file near the end of the 

TAPE IN THE EXAMPLE ABOVEj-WHILE p |P WOULD PUT THE SAME FILE RIGHT IN THE 
KIDDLE - EITHER WAY YOU WOULD BE UNHAPPY. 1 THE ONLY CURE IS TO FALL BACK 

UPON P|P TO PACK ALL THE EMPTIES TOGETHER WHICH MEANS THAT YOU HAVE THE 
DEVICE LENGTH PROBLEM AGAIN. 

Obviously OS/12 users need a good copy facility which could determine 

THE NUMBER OF WORDS/BLOCK ANO COPY UNTIL REACHING THE END OF THE TAPE (OR 
A PREDETERMINED NUMBER OF BLOCKS). SUCH A PROGRAM WOULD ALSO REMOVE THE 
PROBLEM OF SUBMITTING NON-STANDARD TAPES TO DECUS. We ALL LIKE TO PUT AS 

much 'stuff 1 on a tape as we can, but without the existence of a versatile 
copy program we are pretty much limited to sending tapes with only 730 
blocks of information. 

The above was not intended to be (and most certainly is not!) a complete 
oiscussion. Hopefully it will be helpful to •new 1 users of OS/12 who come 

UPON THE SCENE, AS THE AUTHOR DID, WITHOUT A LONG ASSOCIATION WITH THE 

PDP12-UNC8 world. Others who have more accurate information, or other 

•DE^S CN TnESE TGPJCS, ZnZ cHCSUnAGcD TO COriTiwut THE DiSCOifSSE in FUTURE 

OS/8 Newsletters. 
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E TOS COMMENTARY 

Reverend Chase writes: 

Dear Bob: 

I think — reflecting a little on the past h years - that no small amount of 
end-user grief is related to the extraordinary turnover in the industry. I 
lived for 3 years in the shadow of the Vatican, but the $yzantine politics 
and palace revolutions within (one example only) the Edu-Group, or the turn- 
overs in PDP-8 software personnel, could teach the very- and right-rev. 
Monsignori sume new tricks ! Sitting for a moment and thinking of people one 
used to know who are now .. who-knows-where brought this home to use. 

(A parson's beef: I wonder if the country in general hasn't undervalued con- 
tinuity and over-rewarded the flash in the pan, the razzle-dazzle high-pressure 
short-lived performance. Th^re are bitter moments when one thinks that perhaps 
the 'con' man is our national hero.) 

I approached ETOS from a different angle , which probably explains the dif- 
ference in our reactions. It was a viable solution to an otherwise miserable 
situation, namely, that without it one has only two ways of using his system 
in a school: 

#1.) Run a multi-user 'BASIC or BEOTS FOCAL-5/69 ("QUAD' is very slow) as 
the only available language or level of language; or, 

#2.) Pre-empt the system for oneself or for one gifted student and lock out 
everyone else in the school. 

Another factor is that I have hopes of tying in some treasury work eventually, 
again, the same problem. 

ETC® appears to be a practical answer. One can 'fine-tune' the privileges 
and protections on accounts so that the expert user (well, relatively expert 
as our experts go hereabouts!) is not too confined and yet the run-of-the-mill 
user can't bomb the whole system. Most FOCALs, for example, are far too 'friendly' 
and will cheerfully blow up given certain commands. Ho matter - type *VS 
return and 'boot ' and your private OS— 8 is recreated. The public SYS : area is 
write-locked to normal users, a necessity in a school. Most 'bombs' will not 
wreck the user's private DSK:, but this too can usually be recovered. 

The next version of ETOS will, I understand, support more devices. DF-32/RF08 
and TC08 were mentioned. And a usage log file will be kept along with JOBnn.SBK 
in account 0,3- I rewrote the 'ACCNT* program to get rid of user padding 

of names {%%%&) and it has been improved in other ways sinc3. 

There's quite a group of 6100 and 6200 functions available. TIME/R can be 
incorporated, e,g. , in "batch* Jobs to clock run-times. 

You once remarked that it's a nuisance coding routine I/O, ECHO, maybe rub- 
out features into every single separate machine-language program. The ETOS 
system handles all this with pretty decent buffers and can be set (by program or 
from keyboard) for things like tS, +Q, tC, +0, +P, U plus a wide choice of 
break masks. I used three different sets of status ('KSTAT') words in the 
FOCAL I was toying with. 
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t$y "13!:" pseudo-line printer handler for console recoded easily and made use 
of system options, e.g., it enables +P if and only if the calling program did, 



like "FOrP'. 
an essential. 



It's available to each of our 3 users - with the DECwriter, it's 



EDUCOMP is mainly "EDU" (i town budget) oriented. They pretty weH standardized 
on the 8/E & successors some time ago. The obvious device for swapping on the 
8/E etc., is the BK05/EK8E, because TD8E DECtape has just soared, TC0<3 is 
astronomical, a large EF08 beyond imagination for many of us. DEC is - or so 
I think - deliberately trying to drive DECtape out of existence. The true 



faith in Maynard is floppies (and I don't think very much Oj 
seen ! ) . 



the ones I've 



I find the BK05 reliable, with some care. Keep it clean & the disks as well; 
not having any rugs or upholstery around almost certainly helps (all fuzz 
on records in our F.M- station is the same color as the rug ... gives one to 
think). 



From: JOHH YOUHGQUIST 



/ADDITION TO OS/8 EDITOR TO ERASE CHARACTER FROM CRT TERMINAL 

/FITS IN HOLE @ 2762 

/ 

/ 

/OVERLAY PAGE CONSTANT "BACK SLASH" WITH "BACK SPACE" 

/ 

00104 0210 BSPAC, 210 /BACK SPACE 

/ 
/ 
/OVERLAY RUBOUT ROUTINE WITH "JMP ERASE" 

/ 

01522 5723 JMP I .+1 /GO TO ERASE ROUTINE 

01523 2762 ERASE /ERASE CHAR FROM CRT 

01524 1017 RBRET, TAD AXIN /GET LAST WORD OF INPUT 
/ 

/ 

/ROUTINE TO ERASE CHARACTER FROM SCRENE 

/ 

02762 1104 ERASE, TAD BSPAC 

02763 4470 JMS I 0UTL1 

02764 1026 TAD C240 

02765 4470 JMS I 0UTL1 

02766 1104 TAD BSPAC 

02767 4470 JMS I 0UTL1 

02770 5771 JMP I •+! 

02771 1524 RBRET 
/ 



/GET BACK SPACE 
/BACK UP CUSOR 
/GET SPACE 
/ERASE OLD CHAR 
/BACK UP AGAIN 

/RETURN TO RUBOUT ROUTINE 
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BECflUSE SOME OF THE FOLLOWING INFORMATION DI> NOT MAKE IT INTO THE 
NEW DECUS CATALOG IT IS PRESENTED HERE TO MR :E IT AVAILABLE BEFORE 
THE NEXT CATALOG IS PREPARED. 

DECUS NO. 8-882 



SSP: SCIENTIFIC SUBROUTINE PACKAGE 

SANDIA LABS <IBM> AND H. DAVID TODD <WESLEYA ! UNIVERSITV> 
CONVERTED FROM DECUS ±8-±0±A BV ROBERT HASSI!?GER 
<LIBERTY MUTUAL RESEARCH CENTER, HGPKINTON, i iASS. > 
AND LARS PALMER <HASSLE, SWEDEN) 

THE SCIENTIFIC SUBROUTINE PACKAGE <SSP> IS A COLLECTION OF OVER 258 
FORTRAN IV SUBROUTINES FOR SCIENTIFIC AND M fTHEMATICAL APPLICATIONS. 
OVER 288 OF THE SUBROUTINES ARE PROVIDED IN BOTH SINGLE AND DOUBLE 
PRECISION VERSIONS. THE SSP IS R CO .LECTION OF I/O FREE 
COMPUTATIONAL BUILDING BLOCKS THAT CAN JE COMBINED WITH USER'S 
INPUT, OUTPUT AND COMPUTATION ROUTINES TO BUI J> COMPLETE APPLICATIONS 
PROGRAMS. 

TAPES 1 THRU 5 CONTAIN THE COMPLETE £ >P WITH COMMENTS. TAPE S 
CONTAINS ALL OF THE SSP THAT DOES NOT REG JIRE A DOUBLE PRECISION 
CAPABILITY WITHOUT COMMENTS. TAPE 7 CONTAINS THE PARTS OF THE SSP 
WHICH REQUIRE A DOUBLE PRECISION CAPABILITY WITHOUT COMMENTS. 

THE COMMENTS IN EACH SUBROUTINE FILE <TAPES L-5 ONLY) PROVIDE LIMITED 
DOCUMENTATION. FULL DOCUMENTATION IS AVAI _ABLE IN IBM MANUAL NUMBER 
GH28-8285-4 WHICH IS NOT AVAILABLE FROM DECU > AND MUST BE OBTAINED 
SEPARATELY BY THE USER. 



MGNITOR/QPERATING SYSTEM 
CORE STORAGE REQUIRED: 
HARDWARE REQUIRED: 
OTHER SOFTWARE REQUIRED: 
SOURCE LANGUAGE: 
RESTRICTIONS: 



AVAILABILITY: 



OS/8 

8K MINIMUM 

ANY OS/8 CON-IGURRTION 

OS/8 FORTRAN IV 

FORTRAN IV 

SOME ROUTIhES MUST BE MODIFIED BV THE 
USER TO FVOID OS/8 FORTRAN IV 
RESTRICTIONS A FEW OTHER ROUTINES 
SUCH AS RFNDU ARE UNUSABLE UNDER 
OS/8. 

TAPES 1 THRU 5 ARE AVAILABLE AS R SET 
FOR $±00 ON DECUS SUPPLIED DECT APES 
OR $46 ON L5ER SUPPLIED TAPES. TAPES 
6 AND 7 ARE AVAILABLE SEPARATELY AT 
*28 < DECUS TAPE) OR *8 <USER TAPE> 
EACH. 



NATIONAL LOSS CONTROL SERVICE CORPORATION 



Lon» Grove, il_ 60049 • 312 1 540-2400 



KempER 
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June 4, 1976 



Mr. Kenneth H. Olsea 

Digital Equipment Corporation 

Maynard, MA 01754 

Dear Mr. Olsen- 

Enclosed is a copy of a letter sent to you a month ago. 
While I do not expect you to personally respond, I do think 
that my questions c xe reasonable and warrant a response. 

To-date, I have received no comments or acknowledgements 
from Digital. Since I am in the process of evaluating 
central processors and peripheral equipment for our 
company's future delta processing needs, and this equipment 
includes a PD*P-11/' T among the processors being evaluated, 
we would like to know that when we do have questions regarding 
Digital hardware and software that we can receive a reasonable 
response to them. 

Thank you for your assistance. 



Very tru 




R. Dotti, P.E. 
Manager, 
Noise & Vibration Services 

NHD/saa 
enc. 
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April 28, 1976 



Mr. Kenneth H. Oleen 

Digital Equipment Corporation 

Maynard, Massachusetts 01754 



Dear Mr. Olsen: 

1 am writing to you because of a problem which normal 
channels have been unable to satisfactorily sol vs. For . 
the record, our salesman looked into the situation for us 
and was given an answer to relay to us. X believe he has 
done his job, but that what he was told is not satisfactory. 

I am referring to the new prices for the maintenance 
releases of the OS/0 operating system and related software. 
In our configuration ^ra are using three different products 
consisting of the basic OS/8 system, the extension kit, 
and FORTRAN XV. In the past, maintenance releases have 
cost. $50 per product. This, we were told, paid only for 
the cost of duplication. When enhancements were added, as 
occurred between versions 2 and 3 of OS/8, a slight 
additional charge was added. 

When version 3C was announced at the last DECUS symposium, 
I issued a purchase order for these three maintenance 
releases. X was then told that the price for the main- 
tenance software (please note that X an stressing the fact 
that these are maintenance items, containing fixes to 
software problems X is now $150 for OS/8, and $175 each for 
the extension kit and FORTRAN IV. These costs, X am told, 
only pay for the cost of duplication. 

While X am an engineer, X have had some training in 
economics. In my present capacity, I am also manager of a 
profit center, so I have a feeling for what it costs to do 
various things. With this as background information, as 
well as the costs for various DEC products and manuals, it 
is my contention that these prices are very much in excess 
of what it should be costing DEC to supply these maintenance 
releases . 
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Mr. Kenneth H. Olsen 
April 28 # 1976 
-2- 



By way of illustrating this, let us look at what it night 
take to perform this service. ihe necessary main frame, 
dual DECtape drive, memory and terminal could, I am sure, 
be purchased for $30,000. Faying off this capitol ex- . 
pendlture over five yoars, and at 836 per year yields a 
five year cost of approximately $44,080, or $8,816 on a 
yearly basis. Monthly maintenance on this system would be 
on the order of $125, for a total annual cost of $1,500 
pair year. 

Since it does not take a software engineer to duplicate 
ami format DEC tapes, I am assuming that the salary and 
fringe benefits for such a person is $10 per hour. This 
is by no means unreasonable, and it probably would cover 
room rent at the same time. At this figure, the annual 
coiit for an operator is $20,800 for a 52 week year. This 
gives a total per year cost of approximately $31,116. * 

To be fair, we cannot assume that the system (including 
this operator) will be productive for a full 52 weeks. 
Bsifuming a two week vacation and two weeks for down time 
due to equipment problems, the above cost would be spread 
out over 48 weeks, resulting in a weekly cost of $649. 
Again, assuming the operator/machine system is not fully 
productive during a day, but that i* can function for 
seven hours per day, this results in an hourly cost of 
approximately $18.54. 

Having formated and copied many DEC tapes, I feel that a 
figure of six tapes per hour (formating and copying) is 
not unreasonable. Distributing this hourly cost over six 
tapes results in a duplication cost of approximately $3.10 
per tape. 

Of course, there are other costs involved. Figuring a roll 
of unformated tape at $8.00, $5.00 to process the order 
(per roll) ,- $2.00 to mail the completed tape, and $5.00 for 
documentation (one person told me that updated manual in- 
formation was being sent with the software) , this totals 
to approximately $23.00 per roll. 
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Mr. Kenneth H. Olsen 
April 28, 1976 
-3- 



I have been told in the past th&t DEC does not make a 
profit on this. However, giving yon a 3056 before tax 
return would raise the price to approximately $33.00. 
This is close to $50.00, but a far cry from $150.00 to 
$175.00 per software release. Of course, there are 
undoubtedly a few things I have missed, but my figures 
cannot be very far off. if they axe significantly incor- 
rect, then I suggest that something is very wrong with 
some part of your order processing and * software 
distribution system. 

I do not object at all to paying for software enhancements. 
Ho w eve r, when a Software Product Description states that 
the product I am buying will perform in a certain manner, 
and then it fails to perform in that manner, X do not 
expect to be overcharged for the correction of those 
errors. Reasonable duplication costs are to be expected, 
but I do not consider the current prices to be at all 
reasonable. It may very well be that with the changes 
that are apparently being made in the PDP-8 area that 
software development and other costs are being loaded into 
the costs for the software maintenance releases, if this 
is the case, then I would much prefer that you simply 
state this rather than pretend to the end users that it is 
costing you $150.00 to $175.00 to copy a roll of DECtape. 

At the last DECUS meeting DEC representatives told us much 
about the "software guarantee*. Several questions were 
raised about the true meaning of a "guarantee 19 and who 
really profits by it. While the PDP-8 users were concerned, 
the PDP-11 people were considerably more disturbed because 
their software products are much more expensive. New 
revisions and maintenance releases can become extremely 
expensive over a short period of time. As a potential 
user of a fairly large PDP-11 system, I hear on one hand 
about "software guarantees" and other related benefits, 
but on the other hand see the costs of maintenance releases 
of software increasing 300-^6. 
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Mr. Kenneth H. Olsen 
April 28, 1976 



The extra $350.00 does not particularly concern me. What 
does concern me is that this may be a leading indicator of 
things to come. Any comments you have on this subject 
would be appreciated* 



Very truly yours. 



Norman R. Dotti, p.s. 

Manager, 

Boise & Vibration Services • 



HRDtep 

CCs DECUS OS/8 SIG 
Bob Bassinger 
Coordinator 

OS/8 Special Interest Group 
c/o DECUS 
146 Main Street 
Maynard, Massachusetts 01754 

bcc: Ernest Ciccone 

Digital Equipment Corporation 

5600 Apollo Drive 

Rolling Meadows, Illinois 60008 
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June 15, 1976 



Mr. Norman R. Dotti, P.E. 

Manager 

Noise & Vibration Services 

National Loss Control Service Corporation 

Long Grove, Illinois 60049 

Dear Mr. Dotti: 

I would like to apologize for both the lateness of this response, 
and the misinformation you have received regarding pricing of 
some of our software products. I realize that our evolving 
policies relative to software licensing, pricing, and "guarantee" 
represent a perceptible change in the PDP-8 software world, 
but our intent has always been to minimize the impact of 
these changes. Please allow me co attempt to explain our 
policies so that you can better understand why we feel they 
are of mutual benefit to both customers and Digital. 

1. Past "Maintenance Release" pricing: During the early 
years of our software licensing program, a number of 
our software products, including OS/8 and RT-11, priced 
update releases to recover the costs of media, duplication, 
and handling. This was done also to encourage customers 
to obtain the latest versions of software, in order to 

get maximum utilization of our maintenance efforts, 
as we better understood the costs of software, it became 
necessary to try to recover part of our development and 
support costs , in order to continue to justify, from a 
business/investment standpoint, the software engineering 
efforts required to properly support our large customer 
base. We have tried to adopt a middle of the road approach, 
understanding the previous expectations of our customers, 
yet experiencing increasing pressure to justify the 
substantial software engineering investments needed to 
support our users. 

2. "Software Guarantee" and "Maintenance Release" pricing: 
Having now had substantial experience with our software 
licensing program, we are implementing the following 



5'J».JiPiV'E. B iT COSPOha:!-:'! t.-u; vain CTRc". ".xyiw-iD. va'V.a " 
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Mr. Norman R. Dotti x 

National Loss Control Service Corporation 

June 14 , 1976 

Page 2 



policy relative to maintenance release pricing: 

a. During the first year following purchase of a 
software license, in addition to the support provided 
to the customer depending upon the support category 
of the software product, software updates (which 

may or may not include enhancements or new options) 
which become available will be provided at a price 
equal to the list price of the actual distribution 
media on which the software is written. For 
example, $12 per reel of DECtape. 

b. Following the first year, one or both of the following 
options are available? 

(1) For most major products, a one year subscription 
service is available which provides a continued 
level of support to the customer (typically 

SPR service and subscription to the maintenance 
periodical) plus a copy of each software update 
which becomes available during the year. 

(2) Software updates which become available may also 
be purchased separately. Pricing for customers 
not covered by the initial one year period or 
subscription service will be based on various 
criteria, such as product content, engineering 
development cost, duplication cost, etc. 

I hope this explanation clarifies Digital's intent. If you 
would like additional information, or examples of pricing for 
current products, please call me at 617-897-5111, extension 2381, 
Please be assured that we are most concerned with insuring that 
our policies are clear, and in keeping with our commitment 
to quality products which provide the right solution to our 
customer's problem. 



Very truly yours, 



y*SY44\— 



William H. Munson 
Software Product Manager 



/lm 



cc: 



Mr. Kenneth Olsen 
Mr. Ernest Ciccone 
Mr. Bob Hassinger 
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